Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/security/doc/clippings/911204-01

Internet Message Format | 1991-12-04 | 6.2 KB

From: [e-mail] (Peter Lamb)
Newsgroups: alt.security,comp.unix.admin
Subject: Re: NIS and password security
Message-ID: <prl.691873839@iis>
Date: 4 Dec 91 19:10:39 GMT
References: <#hpq#[e-mail]> <[e-mail]>     <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH

There have been a number of queries and some not completely accurate
information posted on this question. I'll try to summarise the problem and
suggested workarounds. None of the workarounds is particularly satisfactory,
and I'll try to give a reasonable summary of the pros and cons.

The problem is this: ypserv is totally indiscriminate about which machines
it will respond to queries from. Normal NIS maps can be read by anyone
on the Internet who can route packets to your NIS server and back.
"secure" (HA!) NIS maps like passwd.adjunct can only be read if the querier
is using a privileged port (< 1024). This means that anyone can read your
"secure" maps if they can crack root on some machine on the Internet
and can route packets to your machine.

The bug means that many machines on the Internet which use NIS are
vulnerable to having their password files stolen and run through "Crack" or
similar. Arguments about whether distributing Crack and fast U*ix encryption
algorithms was a good idea aside, every wannabe cracker now has a copy
of a reasonably state-of-the-art password guesser.

As I said in my earlier post on this subject, the combination "I'm NIS
and I serve everyone" and easily available password guessers has already
led to breakins at some sites.

This bug was reported to Sun in April 1990, and CERT has also been aware
of it for about the same length of time.

I am told that the bug will be fixed in NIS+ or NIS3.0, or whatever it's
called this week, which I understand will be available in Solaris 2.0.


What to do about it:

1) The Sun Party Line. "Don't run ypserv on your gateway and disable
   IP forwarding on the gateway". This is commonly known as a
   "firewall" (provided the machine is also in other respects
   reasonably secure) and is probably already done by many commercial
   users of the Internet. It is not the greatest in convenience, and
   most University sysadmins would encounter, lets say, a little user
   resistance. Managing the gateway is also a pain.  Switching off
   `routed' alone, as has been suggested here, is usually insufficient.
   However, provided the security of the firewall is not breached, you
   are safe from this attack, and many others. Instructions on how
   to disable IP forwarding in the kernel are in Sun's Network Admin
   manual.

2) The Lamb Party Line. If you communicate to the outside world through a
   smart router, filter out packets coming from external connections
   addressed to destination ports sunrpc/udp&tcp (port 111) and ports
   600-1023, tcp&udp. This will prevent access to *all* sunrpc services
   from outside the router. It will also block access to the Kerberos
   protocols (probably also not a bad idea given the info. in Steve
   Bellovin's paper about Kerberos security problems), and will
   probably block the BSD `r' (rcp,rlogin, etc) commands, but don't
   count on it doing so.  If you and your router are smart enough, you
   may be able to make the `r' commands work.  Eg, for rlogin, allow
   the packets through iff their source is 513/tcp (this opens up a hole
   for a sufficiently clever cracker, though). Blocking port 111 alone
   is insufficient but will block the most obvious attacks (including
   those I've been told have already actually occurred).

The above two solutions are the only real answers to the problem. There
are some workarounds which make life harder for the potential cracker.

1) Choose a hard-to-guess NIS domain name. The cracker must be able to guess
   your NIS domain name in order to talk to ypserv. This is purest security-
   through-obscurity. The domain name is normally only handled by
   automatic systems, and can be up to 64 characters long. Making the first
   part a reasonable handle may help system administration. Something like
    my-old-domainname-Ldp.T2d9wCY
   is probably reasonable. This precaution is vulnerable to "social
   engineering" attacks, ie. the cracker trying to fool a user at your site
   to reveal the domain name, since the NIS domain name can be discovered by
   any user on your machines.

2) Use passwd+ or npasswd to vet passwords. If you do this, you need to
   make all your users put their current password through the new
   password program. Using a premptive check on passwords for idiotic
   usage is a good idea anyway, independent of whether you use NIS or
   not.  If you have Suns and you'd rather spend money than install
   free software, Sun Shield (TM) also provides this capability, along
   with other more or less useful things.  Convex provides some similar
   capabilities in their passwd(1) program.  Some other manufacturers
   may also have similar capabilities. The more sites that do this, the more
   frustrating it will become for crackers trying to guess passwords.



Note that this problem is common to all versions of NIS or Yellow Pages,
that I know of not just on Suns. It will probably go away in NIS+ aka NIS3.0,
but it seems that this will be a little while coming, and for non-Sun
machines even further off.

Using NIS in combination with Sun's so-called `C2' security will *not* help.

For those not aware of current technology in password guessing programs,
Alan Muffet (?sp) "Crack" program can test > 500 guesses/sec against
a U*ix encrypted password on any modern RISC workstation. This means that
an encrypted password can be checked against the entire /usr/dict/words
in less than a minute. "Crack" has been posted to the network, and you
can assume that most crackers and wannabe's have a copy.


Peter Lamb ([e-mail]) (depressed)


PS: Sorry, I will not respond to requests for more details about how to
    exploit this hole. Sun and CERT have full details. If you have a Sun
    s/w maintenance contract, the escalation SO# was 484666 and the Sun BugId
    was 1036869. Please contact Sun if you feel you need more details.